Type of PR:

• Bugfix
• Feature
• Documentation
• Other

Required reviews:

• 1
• 2
• 3

What this does:

This PR extends PenaltyBoard with a fixed compensation model for stakers:

• a constant amount per period in a configurable ERC20
• withdrawable by the staking provider, owner, or beneficiary. Tokens are always sent to the beneficiary .
• Compensation is disabled for stakeless stakers.
• Penalties in the “last 4 periods” (configurable window) reduce or zero out compensation for affected periods via a simple factor (no penalties → full; any penalty in window → none for that period). This will be tuned in later PRs
• Compensation logic lives in the same contract as penalty data.
• Penalty storage is staker-centric: setPenalizedProvidersForPeriod appends the period index to each provider’s list; there is no on-chain period→providers mapping (subgraph can provide that view). This is a departure from the original PR Periods and PenaltyBoard contracts #456, where storage was period-centric.
• The contract depends on TACoApplication for roles and beneficiary. Due to migration work currently in parallel (Migration #453, Migration follow-up changes #457 ), for the moment this PR defines an interface ITACoApplicationForPenaltyBoard
• Accrual algorithm is designed to be efficient and allows for accumulated withdrawals.
  • Accrual is lazy (computed on getAccruedBalance and persisted on withdraw).
  • For a staker we take the accrual window from the last settled period (or period 0 if never withdrawn) to the current period.
  • We fetch penalized periods in the range [startPeriod - PENALTY_WINDOW_PERIODS, current].
  • If there are none, we add numPeriods × fixedCompensationPerPeriod.
  • Otherwise, for each period P in the window we check whether any penalty k in that range falls in [P - window, P]; if so, that period gets zero, else full.
• I'm considering renaming this contract to something like StakerCompensation. I may add a commit for this while the PR is still on draft.

Issues fixed/closed:

• Fixes #...

Why it's needed:

Explain how this PR fits in the greater context of the NuCypher Network.
E.g., if this PR address a nucypher/productdev issue, let reviewers know!

Notes for reviewers:

What should reviewers focus on?
Is there a particular commit/function/section of your PR that requires more attention from reviewers?